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Definition 


“Indicator  expansion  is  a  process  of  using 
one  or  more  data  sources  to  obtain  more  indicators 
of  malicious  activity  by  identifying  those  related  to 
currently  known  indicators.” 

~  Some  guy  named:  Jono  Spring  2013 
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Generic  Situation 


1.  Our  host  communicates  with  known  bad  IP 
address 

2.  Host  gets  infected 

3.  Host  communicates  with  a  different  IP  for: 

•  Command  and  control 

•  Exfiltration 

Let’s  try  and  find  these  second-level  IP  addresses 
•  They’re  bad 
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What  we  need  to  do 


1.  Detect  our  host  communication  with  black  list  IP 

2.  Keep  a  list  of  these  hosts 

3.  Track  the  IPs  where  these  hosts  send  traffic 

4.  Count  how  many  hosts  contact  each  IP 

5.  Alert  if  some  number  of  hosts  contact  an  IP 

6.  Record  those  IPs  in  alerts  and/or  IPSets 
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Disclaimer 


This  algorithm  is  generic 


Threshold  values  in  the  example  are  just  examples, 
they  are  not  to  be  used 


This  is  not  being  run  anywhere 


Illuminates  a  way  Analysis  Pipeline  can  implement 
existing  analysis  ideas 
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Needs  /  Decisions 


•  Need:  Accepted  malicious  IP  list 

•  SiLK  IPSet:  badIPs.set  will  contain  these  IPs 

•  Need:  White  list  of  IPs  where  our  hosts  often 
communicate  with 

•  SiLK  IPSet:  safePopularlPs.set  will  contain 
these  Ips 

•  Decision:  Track  our  hosts  for  1  day 

•  Decision:  Use  50  hosts  contacting  second  level  IP 
as  the  threshold,  within  a  36  hour  time  window 

•  Decision:  Dump  list  of  second  level  IPs  in  both  an 
alert  and  IPSet  file  every  6  hours 
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Analysis  Pipeline  overview 

•  Version  4.4.1  publicly  released: 

•  tools.netsa.cert.org/analysis-pipeline 

•  Streaming  analysis  of  SiLK  records 

•  Filters 

•  Internal  Filters  -  “scratch  paper” 

•  Evaluations  /  Statistics 

•  Can  bin  state  based  on  value  of  specified  field 

•  Configuration  file  tells  Pipeline  what  to  do 

•  Simple  config  files  accomplishes  our  entire  scenerio 
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Mechanics  of  Flow  Collection 
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Steps  1  &  2  -  Detect  and  Track 

FILTER  badTraffic 

DIP  IN  LIST  “badIPs.set” 

END  FILTER 

INTERNAL  FILTER  tracklnfected Hosts 
FILTER  badTraffic 
SIP  infectedHosts  1  DAY 
END  INTERNAL  FILTER 
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Step  3  watch  where  infected  hosts  go 

FILTER  nonWhiteListPostlnfected 
SIP  IN  LIST  infectedHosts 
DIP  NOT  IN  LIST  safePopularlPs.set 
END  FILTER 
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Step  4  &  5:  Count  Hosts  Per  IP  and  Alert 


EVALUATION  secondLevelPopularlPs 
FILTER  nonWhiteListPostlnfected 
FOREACH  DIP 
OUTPUT  TIMEOUT  1  DAY 
OUTPUT  LIST  DIP  second  Level  IPs 
<alerting  options... not  discussed> 
CHECK  THRESHOLD 

DISTINCT  SIP  >50 
TIME  WINDOW  36  HOURS 
END  CHECK 
END  EVALUATION 
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Step  6:  Report  Expanded  Indicators 

LIST  CONFIGURATION  second  Level  IPs 
UPDATE  6  HOURS 
SEED  “latestSecond  Level  I  Ps .set” 
OVERWRITE  ON  UPDATE 
END  LIST  CONFIGURATION 
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Full  Configuration 


FILTER  badTraffic 

DIP  IN  LIST  “bad IPs. set” 
END  FILTER 

INTERNAL  FILTER  tracklnfected Hosts 

FILTER  badTraffic 

SIP  infected  Hosts  1  DAY 

END  INTERNAL  FILTER 

FILTER  nonWhiteListPostlnfected 

SIP  IN  LIST  infectedHosts 

DIP  NOT  IN  LIST 
safePopularlPs.set 

END  FILTER 


CERT  Software  Engineering  Institute  GarnegieMelkm 


not  so  hard 


EVALUATION  secondLevelPopularlPs 

FILTER  nonWhiteListPostlnfected 
FOREACH  DIP 
OUTPUT  TIMEOUT  1  DAY 
OUTPUT  LIST  DIP  secondLevellPs 
<alerting  options... not  discussed> 
CHECK  THRESHOLD 
DISTINCT  SIP  >50 
TIME  WINDOW  36  HOURS 
END  CHECK 
END  EVALUATION 

LIST  CONFIGURATION  secondLevellPs 
UPDATE  6  HOURS 
SEED  “latestSecondLevellPs.set” 
OVERWRITE  ON  UPDATE 
END  LIST  CONFIGURATION 
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Questions/comments? 

druef@cert.org 

netsa-help@cert.org 
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